To download a copy of it click here.

Class Auto Parts

Design Document

BY:

Tim Martin

Christopher Douglas

Henry Selby-Hele
Jamie Bonney

 

 
TABLE OF CONTENTS

1. Executive Summary……………………………………………………………………..…3

2. Design Overview……………………………………………………………………………..4

3. System Architecture……………………………………………………………………..5

4. File and Database Design…………………………………………………………….…6

5. Detailed Design…………………………………………………………………………….….8

6. External Interface Design……………………………………………………………13

7. Human-Machine Interface……………………………………………………………15

8. File Server and Active Directory Server………………………………….24

9. Data Dictionary……………………………………………………………………………….26

1.  Executive Summary

1.1 Purpose of this document

Class Auto parts is a business that has been open for a couple of years now.  Over the last year, there sales have more than double.  The business is big and stable enough now that they are in the process of getting a new store set up and opened across town.  They have a need to develop a system that can be used globally between the stores.  This document will lay out all the details and how a system should be set up.  This will then be presented to the owner for his final ok to move forward with the project. 

1.2 Identification

This web base system will be used for both of the two stores.

1.3 Scope

This system that is being made will cover all the basic business functions for the store.  Some of the feature include:

1. Employee time clock
2. Part look up
3. check out
4. Accounting

1.4 Relationship to Other Plans

Currently there are no other plans in place or looked at for this business.

1.5 Methodology, Tools, and Techniques

This system will be a web based system so each employee can access the system from either store.  Web base systems are an each way to make there systems global.  Sure there are security issues that do have to be addressed.  It will be wrote in XHTML and ASP.

2 Design Overview

This system will help you better control your customer information and the history of purchases.  Using this system will help better your warehouse and min/max parts in stock. 

2.1 Background Information

We would want to tell about how we are going to use different drives to store the customer and part information.  This is also where we would want to talk about security and how important it is to put it into place.

We are going to take your company to the next step.  We are going to use different drives to help support all of your needs.  Security is another step we would like to work on.  With the increase security we can help your company to the next level.

2.2 System Evolution Description

Using this new system will help you take that next step.  It will help keep all of your important information organized.  This system is going to help you know what is in your warehouse. 

2.3 Current Process

This is where we would want to put the current process used. 

 2.4 Proposed Process

Describe the proposed process and reference any supporting documents

We are going to use a system at allows you to organize your warehouse.  You are going to be able to know what min/max of  each part.  We will label each part of the warehouse and make sure that everyplace has an area.

2.5 Technology Forecast

Out line the emerging technologies that are expected to be available in a given time and how the impact the future developments of systems architecture

If we start know we could have this system live in six months.  We will do some beta runs to iron out all the bugs.  With this sytems you will see an increase in warehouse function.

2.6 Constraints

Any constraints that are placed upon the system design, such as schedules, codes or technical constraints, such as company’s commitment to a specific development or programming languages.

We will set down and map out the six months and what is need to make this a success.

2.7 Design Trade-Offs

Discuss the trade off involved with the design chosen and the reasons for your choices.  For example an increase in security controls will likely decrease in ease of use; increases in the flexibility of a system typically decrease in the simplicity of the system.  For this reason the designer must decide to put a higher value on some attributes over others.  Some areas to consider include

Flexibility

3 System Architecture

The System is a standard client / server architecture

3.1 Hardware Architecture

·     Dedicated server at each facility that manages services, such as backups and antivirus services.

Database server –(Not sure where the Database will be located)

3.2 Software Architecture

 Client-Server or Three-tier software architecture.  This will allow any of the three tiers to be upgraded or replaced independently as requirements or technology change. 

3.3 Communications Architecture

·    The local area network segmentation for each facility will be used for segregating servers from client computers.

The physical wide area network structure will be a single-hub network.  Single-hub networks have a hub site that connects directly to remote sites.  Since there are two facilities (stores), one of the facilities will act as the hub site and the other as the remote site.    

4.  FILE AND DATABASE DESIGN

Class Auto parts will need a powerful and flexible data design to provide for its current customer base and future growth potential. This will require a powerful relational database system to store all of their customer and supplier records. In this section we will take a look at how this data will be stored, accessed and retrieved. There will also be a data dictionary at the end of this document that will go into more specifics about the actual data being stored.

            Database Management System Files

Our first figure is an entity relationship diagram that will show the logical relationships and interactions among the system entities.

The next diagram will give you a brief overview of what data is stored in the various tables and what tables will be stored in the database management system.

This database system will be indexed. This will be our primary method for accessing data in the system. Since most data will be queried using primary keys, those keys will be indexed and reduce access time. The size of the database will depend on the amount of data stored within. It will grow larger as the company increases in size and has more customers and products to sell.

• Each Part in the Database takes a maximum of 542 bytes of disc space
• The record of each part purchased by a customer takes a maximum space of 24 bytes
• The record of each part the store purchases takes a maximum space of 20 bytes
• Each customer that is stored in the database takes a maximum space of 377 bytes
• Each Store that is stored in the database takes a maximum space of 382 bytes
• Each supplier stored in the database takes a maximum space of 377 bytes

The database will be updating on an hourly basis. Customers will order parts throughout the day and thus the orders table will be changing constantly. The Parts table will only change when a new part is added or an old part is deleted. Those types of changes may occur on a weekly basis. Suppliers will be added or removed as needed but this is a rare occurred. These types of updates will occur at most every few months.

5 Detailed Design

5.1 Hardware Detailed Design

Due to there being two stores, there will be twice the need of most hardware.  Each store will require 2-3 check out computers.  With each check out computer will be one LCD monitor and one printer to print receipts.  There is not much local storage needed because most of the information is stored on the server.

Inside each store there will be 3 or 4 machines that are used for part lookup and day to day operations.  (Example purchasing, inventory mgt, account).  Each of these machines will have 1 LCD monitor and 1 printer.  There is not much local storage need because most of the information is store on the server.

All the machines in the company will have a standard P4 3.0GHz and 512 memory.  The hard drives with be a standard 40GB.  This will last a very long time for basic operations.

 

5.2 Software Detailed Design

The software system for the two stores is a global system.  When ever you turn on computers in either store, it will ask you to indentify which store you are in.  Then it will take you to the software for that store.

Module [Inventory]

The module stores all the details about everything that is in stock.  Each item has an Item #, Description, Store Cost, Customer Cost, and qty on hand.  All the module does is simply look up inventory. 

Processing

When you go into this Module you will be present with a blank form.  There you simply fill in as much information as you know.  Then you click the look up button.

Local data structures

--Item #

--Description

--Store Cost

--Customer Cost

--Qty on hand

Module[Inventory Update]

This screen looks similar to the Inventory module.  This one allows updating to be done to the stock. 

Processing

Works almost the same as the Inventory module, but this allows adding and removing products from inventory.

Local data structures

--Item #

--Description

--Store Cost

--Customer Cost

--Qty on hand

Module [Sales Checkout]

This module is used at the checkout counters in the store.  To check out a person you simply enter the Item # and the qty into the check screen.  Then click the payment module.  Once the payment is done, the inventory update module runs.

Processing

When you go in and use this module, you simply will enter the item# and qty in the check out screen.  All the rest of the fields will pull from the inventory module.

Local data structures

--Item#

--Qty Purchased

Module[payment]

This module is used to process payment.  Payment accepted is cash, check, or credit card.  Once the payment module is ran it will ask you what type of payment.  You click on the type you have.  Then depending on the type of payment another payment screen comes up.  The three screen that might come up are payment screen, check screen, or credit card.

Processing

This is processed the second you click payment on the Sales screen.

Local data structures

--Credit Card #

--Expiration Data

--Checking account #

--Total tender

--Cash back

Module[InventoryUpdate]

This module is run at the same time payment is collected.  It simply deducted what is sold for the inventory.

Processing

This will take the raw data and subtracts it from in stock inventory.

Local Data Structures

--Item #

--Qty Purchased

5.3 Communications Detailed Design

There will be two servers.  One server will be place in each building.  Store #1 will be the main server.  The two stores will be linked up via T1 lines.  The system will work off of a live update process.  The second a part or item is sold, inventory levels will be updated.

6.  External Interface Design

The main Auto Store and the new addition will be under development to tie both in them together on the say system. 

6.1 Interface Architecture

Both auto stores will have interface architecture.   Both must have access to parts (bought and sold), suppliers, customers’ orders and customer information.  We would implement the interface that would allow them to access this information.

6.2 Interface Detail Design

Both auto stores would want to have access to part look ups, check out process, accounting and have an employee time clock. 

·         Must have customer name and number to place order

·         System will error out if customer name and number is not put in

·         Must be able to send information from store one to store two

·         must be able to run a query to find the customer and number

Each data element must provide name, store, send, access and receive.

·         Names/identifiers

o        Part name

o        Part number

o        Customer name

o        Customer number

o        Supplier name

o        Supplier number

Data elements assemblies that the interfacing entity will provide, store, and send

·         Names/identifiers

o        Each part should be stored by name and number

o        Each customer should be stored by name and number

o        Each supplier should be stored by name and number

Describe the communication methods that the interfacing entity will use for interface

·         Systems

·         E-mail

·         Transfer data with excel

·         Routing

·         Transmission services

·         Safety

·         Security and privacy considerations

Describe characteristics of the protocols that the interfacing entity will use for interface

·         Procedures of everything done through out the auto stores

·         Packaging

·         Legality checks and error control

·         Recovery procedures

·         Synchronization

·        Status, identification, and reporting features

7. Human-Machine Interface

The system will provide smooth interaction between man and machine. This will allow the user to retrieve and process the data they need quickly and efficiently, without the need to study extensive manuals. The interface design rules, inputs, outputs, and navigational hierarchy will demonstrate how this will be accomplished.

7.1                           Interface Design Rules

Since the system will be extensively used by end users, we will use a user-centered design approach when creating all of the interfaces. There are four elements to all interfaces that must be met to full fill our design philosophy.

Visibility – The visibility of the document should allow the user to understand how the page functions. Important functions, such as navigation, should be emphatic. A page with excellent visibility will allow the user to know what they can or cannot do on a screen with a simple glance.

Accessibility – Accessible documents allow the user to find information quickly and easily no matter how long or short the document is. Breaking the page into smaller pieces and having a visible navigation system will help with this.

Legibility – A legible page is one that can be easily read. In short, the text on the page should be easy to read.

Language – The language of the page is the grammar of the page. Short simple sentences are preferred. Jargon is to be avoided and active voice is always preferable.

All pages will also strive for Strive for consistency. This goal will be achieved by using a common template for all interfaces in the process.

7.2                           Inputs

There will be multiple ways to enter input into the system. The two most common methods will be data entry screens and bar code scanners. Access to the system and to all data entry screens will be based on the operator’s role. Below you will see how these two methods of input will be used.

Data Entry Screens

·        On these screens the data will be keyed in.

·        Entering data into the Sales System will be open to all users.

·        Entering data into the Inventory System will be limited to management.

·        All data entered into the system must be verified. This process will be automated to ensure that malicious information does not make its way into the system.

Bar Code Scanners

·        Bar code scanners will primarily be used with the sales system.

·        Operators will be able to scan in items for purchase instead of keying the data in manually

·        Since this is part of the sales system it will be accessible by all users.

·        Once again all data scanned in will be verified against the database to make sure it is accurate.

7.3                           Outputs

Each of the three systems, Sales, Inventory, and accounting, will have their own outputs. Access to the outputs of each system will be based on the operator’s role. Output will mainly come in the form of reports that can be viewed either on a monitor or printed out for retention.

 

Sales Output

·        Sales output will be available to all system operators.

·        The only output the sales system will have will be receipts.

·        Receipts can either be printed or viewed on a monitor.

·        Printed receipts will be supplied to all customers at the point of sale.

Inventory Output

·        Only management and above will have access to these outputs.

·        Reports will be generated daily stating the level of inventory for each store.

·        Reports can also be generated to view inventory related trends

·        A monthly report will be generated detailing the rise and fall of inventory levels for each part.

Accounting Output

·        Only management and above will have access to these outputs.

·        Reports will be generated daily for each store indicating how many sales were made and what the net income was.

·        Monthly reports will be generated that detail every sale made.

·        Reports can be generated as needed to find information such as the most profitable item sold.

7.4                           Navigation Hierarchy

7.4.1                     Customer Selection Screen [x.1]

7.4.2                     Add New Customer Screen [x.2]

.

7.4.3                     Customer Data Screen [x.3]

.

7.4.4                     Customer Data Screen [x.4]

7.4.5                     Receipt Screen [x.5]

7.4.6                     Supplier Selection Screen [x.6]

8. File Server and Active Directory Server (Windows 2008 Server)

·        Ability to identify audit information by user identification, network terminal identification, date, time, and data accessed or changed.

·        File level access control.  This allows the owner of a resource to control access to the resource

·        Extensive auditing allows the administrators to audit security-related events and the actions of individual users.

·        User identification and authentication requiring each user to uniquely identify him/herself. The system uses this unique identification to track and audit the activities of the user.

·        The ability to identify and authenticate legitimate users in order to provide them with access to information, content, and services, while denying service to impersonators.

·        Security system with a fine-grained access control that will allow legitimate users access to resources, while protecting sensitive resources from hackers and unauthorized users.

·        Ensure that clients have private and tamperproof communications ove the Internet for commerce and sensitive business-to-business transactions using SSI (secure sockets layer).

Data Integrity Controls / Database Server – All data integrity controls should be tested as part of routine test procedures

·        Replication Services to replicate and synchronize database objects.

·        Data integrity is addressed by a variety of data constraints specified in the database schema.  These constraints describe relationships between tables.

·        Discretionary access control.  Access to objects is restricted to specific users or groups of users.

·        Transactions to ensure that any operation either totally completed or is undone if it fails.

·        Concurrency to allow multiple clients to use the same database.

·        Suspended transactions checks and reports

·        Duplicate record  / data checks

IT Infrastructure Controls

·        Data & backup recovery process for all environments.

·        System monitoring procedures

·        Application change control procedures

·        Database configuration control support

9. Data Dictionary

Customer Purchases Table

Parts Table

Customers Table

-         Part Purchases Table

-         Stores Table

-         Suppliers Table